-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Remove unnecessary lock from count() method #4352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Anand Rajagopal <[email protected]>
|
This seems reasonable to me. Have you tested it with the race detector just out of interest? |
Do you mean the following? |
Not the tests, but run a build Alertmanager of with this patch with the race detector enabled. |
Will do this and report back |
I built AM with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! Reviving this thread since it looks like it got lost in the shuffle.
Given the test pass without detecting a race, the full build passes without detecting a race, and a quick audit of the code shows no potential for a race, I think we should merge this.
Just for posterity:
types.MemMarkerholds it's own lock during the call toStatus: https://github.com/prometheus/alertmanager/blob/main/types/types.go#L263-L264store.Alertsholds it's own lock during the call toList: https://github.com/prometheus/alertmanager/blob/main/store/store.go#L135-L136
I'm pretty sure the mem.Alerts mutex is only meant to protect the listeners slice.
The count() acquires a lock but it is not necessary. The method makes a copy of store alerts by calling
a.alerts.List(). Thea.alerts.List()method acquires its own internal lockSimilarly,
a.marker.Status(..)also has its own lock. Therefore, removing the lock fromcount()should be safe.count()method is called during scrapes and since it acquires a lock, it can cause bottlenecks during scraping